Sys.args() documentation states:

Returns all the arguments that were passed in the command line.

If Sys.args() can now contain values passed using loadfile instead of via the cli, then it is deviating from the specified behaviour.

Also, just because loadfile was used to load the current module, doesn't mean that _G.arg is necessarily nil. The current patch still gives no way to access {...} if _G.arg is not nil.

-- wrapper.lua
local main = loadfile("main.lua")
main("load", "file", "args")

-- main.lua
print("_G.arg = " .. table.concat(_G.arg, " "))
print("{...} = " .. table.concat({...}, " "))

$ lua wrapper.lua real cli args
_G.arg = real cli args
{...} = load file args

I also think it's bad practice to overwrite a global value like _G.arg.

We should also avoid injecting more unconditionally included lua code. Even if it's one line now, it builds up gradually and one of the most common complaints about the lua target is the boilerplate required for simple programs. It is especially something to consider when only some users need it but it is added to everyone's code. Using define feature here to conditionally generate the extra line avoids this problem.

Maybe it's better to have a new method like lua.Lib.getModuleVarargs()? That avoids messing with the behaviour of Sys.args and gives full control to the user when _G.arg and {...} both exist but are different.

Finished up a total rewrite. This uses a lua feature module to capture the args, rather than capturing it at the start of every script.